The growth of the Internet has led to the development of numerous technologies for the distribution of content over the World Wide Web. Among these technologies are systems that permit Web content to include executable code that is sent from a Web server to a Web client, where it is executed. Such “mmobile code” or “applets” allow content providers to distribute content that includes programmed behavior, which may be used in a variety of ways. Mobile code systems, such as Java (produced by Sun Microsystems of Palo Alto, Calif.), or Curl (provided by Curl Corporation of Cambridge, Mass.) may greatly enhance the experience of Web users by providing a relatively efficient way for highly interactive or media-rich content to be sent across the Web.
Although such mobile code systems provide access to highly desirable features, they also raise serious security issues. Including executable code in Web content exposes Web users to a variety of attacks. The same systems that provide an efficient way to distribute highly interactive or engaging content also provide a means to distribute malicious code, such as viruses, programs designed to steal information from user's computers, or other damaging programs. Even if such programs are not intentionally distributed, the use of mobile code opens the possibility that errors in executable Web content may have potentially disastrous results on the computers of Web users who view the content. These security issues are made worse by the fact that the highly interactive Web applications that can be designed using mobile code are particularly attractive to Web users, who may be easily induced to view Web pages containing mobile code.
To address these security issues, mobile code systems such as Java typically impose limits on which system resources may be accessed by applets. An applet will typically have only limited access to the file system on a client computer, the CPU, memory, the network resources available to the computer, and so on. Additionally, the programming languages associated with mobile code systems typically include features which enhance security, such as type safety and garbage collection, to prevent inappropriate use of operations on objects, unsafe access to memory resources, memory leakage, and other potential memory-related problems that may be exploited by malicious code.
Unfortunately, despite these efforts, it is difficult or impossible to create a usefull programming language or mobile code system that is completely free of security issues. A clever attacker can exploit minor security holes to effectively completely break the security of a mobile code system, and launch a variety of attacks. Additionally, it is possible to exploit standard network services, such as Domain Name Service (DNS) to assist in an attack using a mobile code system.
One such attack, which shall be referred to herein as a “DNS spoofing attack,” uses a mobile code system, such as Java, plus the DNS system, to attack computers behind a computer network firewall. Such a firewall prevents unauthorized connections from being established between computers behind the firewall and computers outside of the firewall, and thereby prevents a direct attack against computers located behind the firewall. The DNS spoofing attack, which is described, for example, in “Java Security: From HotJava to Netscape and Beyond”, Drew Dean, Edward W. Felten, and Dan S. Wallach, Proceedings of 1996 IEEE Symposium on Security and Privacy (Oakland, Calif.), May 1996, provides a way to indirectly attack computers located behind a firewall, if any of those computers accesses an innocent looking applet from an attacker's Web site.
As will be described in greater detail hereinbelow, the DNS spoofing attack works by an attacker making an applet available on a Web page. When a victim computer, located behind a firewall, accesses the Web page, and runs the applet, the applet attempts to create a network connection with a computer outside of the firewall using the name of the computer outside the firewall. To translate the name into a network address, a DNS lookup is performed. By controlling the address returned by the DNS lookup, the attacker can cause the applet to connect to a second victim computer, located behind the firewall, instead of a computer outside of the firewall. Once such a connection is established, the applet can be used to attack the second victim computer.
To prevent this type of attack from succeeding, Java permits an applet to create connections only with the computer from which the applet was downloaded. The address of that computer is determined by taking the numerical address from the packets of the applet itself, as it is being loaded. Thereafter, the applet may connect only to that exact numerical address. Thus, if an attacker puts a malicious applet on his Web server, that applet will only be able to connect back to the attacker's own Web server—it will not be able to establish a connection with another computer behind a firewall.
While this solution is effective at preventing a DNS spoofing attack from succeeding, it also may severely limit the functionality of applets. There are many instances in which it would be useful for an applet to access resources across the Internet on computers other than the computer from which the applet was downloaded, such as other computers associated with the same service provider from which the applet was downloaded. Since accessing such resources requires that a network connection be established between the computer that is running the applet, and the computer on which the resources are to be accessed, such access is prevented by Java's solution to the DNS spoofing attack, unless the resources are available from the exact computer from which the applet was downloaded.
Additionally, the method that is used by Java to prevent a DNS spoofing attack may not be usable by other mobile code systems. The Java runtime system is typically tightly integrated with a web browser, and is therefore able to access the IP address from which an applet was downloaded. Other mobile code execution engines or runtime systems may be implemented, for example, as web browser plug-ins, which do not have access to such information. Because such systems are not as tightly integrated with the Web browser, they may only have access to the host name from which an applet was downloaded, rather than the IP address. Thus, such systems cannot use the same approach to preventing DNS spoofing attacks that is used in Java.